When two devices on a computer network communicate with each other, they typically do so by creating a connection between them. That connection is identified by the protocol used for communication, and the addresses and ports used by each endpoint. Once a connection has been established, the two endpoints may exchange many data packets. The connection and the packets that are sent in that connection are referred to as a “session.”
Some devices (for example, simple routers) that process traffic on computer networks make packet-by-packet decisions about how to handle network traffic. A set of rules is applied to each packet received by the device, and the packet is then handled accordingly. The rules are applied without regard to what other packets within a session may previously have been processed. Such devices are called “non-stateful” devices, because they handle traffic without regard to the state of the session.
So-called “stateful” devices, on the other hand, operate under the assumption that there will be many packets for each session. They maintain state information about the sessions that they process, thus allowing traffic in established sessions to be processed quickly.
Maintaining state information requires that stateful device allocate resources dedicated to storing that information. One form of attack against a stateful device (as explained below) involves creating false sessions, and by doing so inducing that device to maintain information about those sessions, to the extent that the device no longer has enough resources to process legitimate network traffic.
A stateful device that is aware of the semantics of connection-oriented services, like TCP (transmission control protocol), makes a decision at connection setup time, and then forwards messages more efficiently for subsequent packets in that connection. Finally, when the service semantics indicate that the session is complete, the device stops forwarding packets for that session.
Most packet-filtering firewalls, as well as other devices like Layer-4 switches, make decisions based on the concept of a “session”. The concept of a session is well defined for TCP, since the TCP protocol specifies the point in the message-passing where a connection has been established. For other protocols, such as UDP or ICMP, the concept of a “session” is artificial to some extent, and must be inferred by the relative frequency and direction of packets.
In any case, since a session is a transient concept, network devices must allocate resources, usually amounting to RAM and CPU cycles, to keep track of it. For TCP or UDP, the possible number of sessions at any one time is bounded by the number of modifiable bits in the IP and TCP/UDP headers. IP provides 32 bits of source and destination address information along with 8 bits of protocol information. If the protocol is TCP (6) or UDP (17), they provide an additional 16 bits each of source and destination port information. This totals (32+32+16+16=96 bits or 12 bytes) of possible session permutation information, just for TCP or UDP alone. The universe of possible unique session permutations is therefore on the order of 2^97 or about 10^29 (100,000,000,000,000,000,000,000,000,000 sessions)!
Even if each session took a single byte of RAM in the device, and a single clock cycle to process, keeping track of this many sessions is completely infeasible with today's technology. As a result, there must exist a limit to the number of sessions that any one device can track at a given time. Correspondingly, that device must have a strategy as to how to deal with being offered more sessions than it can track at a given time.
As an example, assume a device can support 10,000 simultaneous sessions. The smallest size of an IP packet containing a UDP segment is 32 bytes or 256 bits (ignoring L2 framing). Over a 56 kilobit/second line (e.g. a modem), a potential attacker could generate 10,000 unique sessions in about 45 seconds. Over a T-1 connection (1.544 Mbps), this same attack would take less than 2 seconds. This action would completely shut down the device until it could remove these sessions from its list of active sessions (usually by idle timeout or other cleanup mechanism).
Such attacks are trivial to generate; many tools exist for generating such traffic and are available for public download today. Distributed Denial-of-Service tools are the latest generation of such tools, where one controller can issue commands to many “zombie” processes which live on compromised systems to coordinate a massive attack at literally the touch of a button. Note however that DDoS attacks are only different from conventional DoS attacks in scale, and that the attack can come from many physical endpoints simultaneously.
The simplest action to take when all available cache memory is used is to ignore new sessions. The difficulty with that strategy is that while it allows existing users to continue working, it prevents new users from accessing protected resources (servers, etc.).
A different strategy is to simply clear existing sessions from the device's memory, and place new sessions in the newly-freed space. That strategy has the drawback that removing existing sessions arbitrarily may interrupt the flow of traffic for valid sessions. It may not be possible to resume or recover those sessions easily (for example, an FTP download that has been running for thirty minutes might have to be started all over again). Thus, it is desirable to have a more efficient methodology to determine which sessions are expendable.